Network Address Translation (NAT) is the process of modifying network address information in datagram packet headers while in transit across a traffic routing device for the purpose of remapping a given address space into another. NAT is used in conjunction with network masquerading (or IP masquerading) which is a technique that hides an entire address space, usually consisting of private network addresses, behind a single IP address in another, often public address space. This mechanism is implemented in a routing device that uses stateful translation tables to map the “hidden” addresses into a single address and then rewrites the outgoing Internet Protocol (IP) packets on exit so that they appear to originate from the router. In the reverse communications path, responses are mapped back to the originating IP address using the rules (“state”) stored in the translation tables. The translation table rules established in this fashion are flushed after a short period without new traffic refreshing their state.
Of course, the use of Network Address Translation means that many hosts in the Internet cannot be contacted directly by other hosts because they are behind a Network Address Translator (NAT) that prevents inbound connections. Different NAT traversal techniques, e.g., Interactive Connectivity Establishment (ICE) [see J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. draft-ietf-mmusicice-19 (work in progress). October 2007] have been developed to overcome this problem, but with certain kinds of NATs the only way to create a peer-to-peer connection between two hosts is to relay all the traffic through a node that both of the peers can contact (including the peer or peers behind a NAT).
Traversal Using Relays around NAT (TURN) [see Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). draft-ietf-behave-turn-15 (work in progress). February, 2009] allows a host (that is a TURN client) to register a “relayed address” (a combination of IP address and port number) at the TURN server such that a session is established “through” the NAT between the TURN server and the TURN client (nb. a connection initiated by the host behind the NAT will generally result in a session being established through the NAT and via which the node to which the connection is initiated can send packets to the host). A connection initiated by a remote peer to the relayed address is relayed by the TURN server to the TURN client, such that it passes through the punched hole in the NAT. The TURN client can send data to the peer via the TURN server such that, from the point of view of the peer, the data appears to originate from the relayed address. Using a TURN server, even with the most restrictive type of NATs, a communication path can be established between two peers.
After obtaining a relayed address from the TURN server, a TURN client needs to maintain its state in the NAT by sending periodic keep-alive messages to the TURN server via the NAT. To minimize the volume of keep-alive messages, TURN allows multiple connections with different peers to re-use the same relayed address. Thus, regardless of the number of peers, only one set of keep-alive messages is required. In addition to reducing the volume of keep-alive traffic, this method also conserves public ports at the TURN server and at the NAT allowing them to serve a larger number of simultaneous users.
In the case where multiple peer connections are multiplexed onto one connection between the TURN client and the TURN server, it is necessary to provide a mechanism which allows the TURN server and the TURN client to identify peers within the data packets that they exchange. For this purpose, data sent between the server and client is encapsulated within TURN messages.
TURN encapsulation increases the per-packet overhead and decreases the Maximum Transmission Unit (MTU) on the link between the TURN server and client. The overhead problem is especially severe in restricted bandwidth environments (e.g., when using a cellular data connection), and for data that is sent in multiple small packets (e.g., real time audio). More significantly perhaps, encapsulation prevents the use of unmodified operating system kernel protocol stacks for receiving and sending the data. This gives rise at least to performance problems, as data needs to be sent back and forth between the kernel and user space process. In the case of restricted operating systems (such as those commonly used in mobile devices) it may of course be impossible to feed the packets back to the kernel protocol stack or capture the packets after the stack processing. TURN encapsulation is not a viable option in such cases.
The Internet (IETF) draft—“Traversal Using Relays around NAT: Relay Extensions to Session Traversal Utilities for NAT (Jul. 8, 2007)” provides a mechanism for avoiding encapsulation. This mechanism makes use of the “Set Active Destination” request. However, the mechanism does not allow multiple sessions to be multiplexed onto the TURN server to client link.